Drivers in the MICROSOFT WINDOWS operating system and other operating system can run in either user mode or kernel mode. User-mode drivers run in the nonprivileged processor mode in which other application code, including protected subsystem code, executes. User-mode drivers cannot gain access to system data except by calling an API which, in turn, calls system services. Kernel-mode drivers run as part of the operating system's executive, the underlying operating system component that supports one or more protected subsystems.
User-mode and kernel-mode drivers have different structures, different entry points, and different system interfaces. Whether a device requires a user-mode or kernel-mode driver depends on the type of device and the support already provided for it in the operating system. Most device drivers run in kernel mode. Kernel-mode drivers can perform certain protected operations and can access system structures that user-mode drivers cannot access.
When a hardware device interrupts the CPU, it puts the CPU in an elevated interrupt priority where all other processing, except higher priority interrupts, is stopped until some device specific code executes to turn off the interrupt at the device. In kernel-mode, the interrupt is masked such that the CPU is not continually interrupted. However, this is not the case in user-mode. When an interrupt reaches the CPU, an exception is invoked and the CPU's exception handling code will run. In the case of an external interrupt, the CPU will start by clearing its interrupt enable flag, meaning it will ignore interrupts until the flag is cleared. This occurs whether user mode or kernel mode code is executing at the time. With kernel mode drivers, however, the interrupt can be handled immediately. However, with a user mode interrupt handler, the processor must return to user mode first, and then service the interrupt. To do this, the interrupts need to be masked at a level below the CPU level, i.e, at the APIC, bus, or device level, to allow the user mode interrupt service routine (ISR) to execute. Thus, device drivers conventionally run in kernel-mode because of the complexity associated with servicing a user-mode device driver.
Accordingly, there is a need for an operating system mechanism to deliver interrupts in user-mode such that additional classes of devices may use user-mode drivers. The present invention provides such a solution.